The Near - Horn Approach toDisjunctive

ion of an InH-Prolog proof. Lost is the localness property of LJ but gained is a more directed backchaining search, where the _-LEFT rule need not be used blindly. It is instructive to note how small a change to the intuitionistic calculus LJ is needed to yield this complete proof procedure for rst-order (classical) logic. (One should note that the conversion of an arbitrary rst-order formula to the normal form for nH-Prolog programs can involve intuitionistically invalid steps.) We now consider further the declarative and procedural readings of a program and the system which processes the program, in particular for InH-Prolog. Program clause H1_ _Hm B1^ ^Bn has the obvious declarative reading associated with a formula in rst order logic. In a Prolog derivation, a continuation L1; : : : ; Li can be read as showing (P [ fL1; : : : ; Lig) j= 9Q, where P is the program and 9Q is the original query. Similarly, a line in an InH-Prolog proof can be given a declarative reading. A line L1; : : : ; Li # A1; : : : ; Aj fD1; : : : ; Dkg can be read as (P [ f:D1; : : : ;:Dk; A1; : : : ; Aj; L1; : : : ; Lig) j= 9Q where P is the program and 9Q is the original query (possibly a disjunction). That is, if the deferred heads are all false (alternative cases do not apply) and all active heads and goals are true, then this together with the program implies the original query. We can focus our attention on a particular block by taking the deferred heads to be false, i.e. by disregarding the alternative cases which correspond to other blocks. The declarative reading of the line is then reduced to (P [ fA1; : : : ; Aj ; L1; : : : ; Lig) j= 9Q within the context of the block. This can be read as (P 0 [ fL1; : : : ; Lig) j= 9Q, the semantics for Prolog with P 0 P [ fA1; : : : ; Ajg. This agrees with our view of deduction within a block as the standard logic programming paradigm with conditional facts (the active heads) augmenting the given program P . Regarding a procedural reading, the clause H1 _ _ Hm B1 ^ ^ Bn is to be regarded as a multi-entry subroutine, callable by any Hi. This reading is valid locally, i.e. within a block. Globally, the remaining Hj must be considered, unlike alternate entry points in standard procedures, but this is a property of blocks. Thus, the useful procedural viewpoint is to consider blocks as cases to be dismissed and the content of each block as the computation needed to dismiss the case. We thus say that InH-Prolog has a local procedural reading. 3 Semantics The second facet of the near-Horn Prolog project has focused on the semantics of disjunctive logic programs from a case-analysis approach. A xpoint characterization of disjunctive programs has been developed [RLS91, Ree91] which generalizes the standard Horn program characterization [vEK76] and agrees with the xpoint characterization of Minker, Lobo, and Rajasekar [LMR89, MR90]. In addition, this characterization matches the nH-Prolog procedures (InH-Prolog in particular) and so provides insight into the workings of the procedures. In conjunction, we have investigated the addition of negation to disjunctive programs 8 [Ree91]. We have considered and implemented both classical and default negation, with each type having relative advantages and natural applications. We envision applications in which both types of negation may be used and must interact. 3.1 Fixpoint Characterization Within the logic programming community, one is often more concerned with the answers computed by proofs than with the mere existence of proofs. Consider an InH-Prolog proof of some query 9(L1 _ _ Lk) in which Li1 ; : : : ; Lij are the atoms which appear as initial goals in start blocks and 1; : : : ; n are the mgu's produced by blocks in the proof. Then we say that Li1 1 n _ _ Lij 1 n is the computed answer clause for the proof. An InH-Prolog proof may be viewed as directly proving the computed answer clause. And since each atom in the computed answer clause is an instance of an atom in the proof query, the computed answer clause logically implies the query. Example 3.1 Consider the InH-Prolog proof in Example 2.2. This proof is described as a proof of a, but it also su ces as a proof of queries a _ b and a _ b _ c. Regardless of the query, this proof has computed answer clause a since a is the only atom which appears as initial goal in a block. Note that the computed answer clause a logically implies each of these possible queries. The InH-Prolog answer set for a program P can be de ned to be those logical consequences of the program which are computed answer clauses in InH-Prolog proofs from P . While all logical consequences of a program are provable using InH-Prolog, not all are computed answers. This is demonstrated by the simple Horn program P = fa; bg which has a _ b as a logical consequence, and yet no InH-Prolog proof from P will have a _ b as computed answer. Thus, an important problem in understanding our procedure is characterizing the InH-Prolog answer set. For the reasons given earlier, the nH-Prolog procedures are very attractive methods for handling disjunctive programs, especially when the number of non-Horn clauses is small (the near-Horn property). However, the proofs of soundness and completeness do not give a feeling for the nature of the answer set associated with the nH-Prolog procedures. It is reasonable to ask if there is a xpoint characterization of the logical consequence set of a disjunctive logic program which re ects the case-analysis approach adopted. We show that there is such a characterization and that it provides insight into disjunctive logic programs not otherwise seen. Our approach is to de ne two operators, a case operator (T c P ) which captures all of the information obtainable via splitting rule cases (corresponding to InH-Prolog blocks), and a join operator (T j P ) which combines this case (block) information to capture the possibly disjunctive consequences of the original program. In addition to characterizing the InH-Prolog answer set, a main advantage of this approach is that the case operator, the operator which makes use of the actual program clauses, still operates on single atom consequences and maintains a close correlation to the immediate consequence operator TP [vEK76]. Disjunctions appear only at the top-level joining of cases by the join operator. 9 Since the xpoint characterization of Horn programs is well understood, as is the caseanalysis approach described here, these two operators provide an intuitive characterization of disjunctive logic programs. NOTE: For ease of presentation, we will describe variants of the operators which correspond to InH-Prolog without the cancellation pruning rule. Variants which correspond directly to InH-Prolog with this pruning rule will be discussed brie y at the end of this section. We rst de ne the case operator which is intended to capture all of the information obtainable via splitting rule cases (corresponding to InH-Prolog blocks). Recall that the splitting rule reduces a problem to cases in which non-Horn clause H1 _ _Hm B1 ^ ^ Bn is replaced by either Horn clause Hi B1 ^ ^ Bn or else fact Hj . That is, the non-Horn clause is either stripped of all but one head or else replaced by a fact which subsumes it. This case-analysis approach is apparent in InH-Prolog where computation within a block proceeds as in a Prolog derivation with two exceptions: (1) when a non-Horn clause is called, it is treated as if it were a Horn clause and the auxiliary heads are deferred, and (2) there may exist active heads which serve as conditional facts within the block. An InH-Prolog block with nal deferred heads D and initial active heads A can be seen as a Prolog derivation of the splitting rule case where the heads in D are stripped from non-Horn clauses and facts in A are added. The case operator T c P operates on sets of triples taken from the space TRIPP = HBP 2AuxP 2AuxP (where HBP is the Herbrand Base of P , consisting of all ground atoms, and AuxP is the Auxiliary Base of P , consisting of all ground atoms which are instances of heads in non-Horn clauses). The triple (L;D;A) is intended to represent that atom L is a logical consequence in the splitting rule case where heads in D are stripped from non-Horn clauses and facts in A are added. De nition 3.2 (Case Operator) Given disjunctive logic program P , L 2 HBP , nite D 2 2AuxP and A 2 2AuxP , and S 2 2TRIPP : (L;D;A) 2 T c P (S) i H1 _ _Hm B1 ^ ^Bn is a ground instance of a clause in P [ A, L = Hi for some 1 i m, and 8j = 1; : : : ; n there exists (Bj ; Dj; A) 2 S, where D = f[Djg [ fH1; : : : ; Hi 1; Hi+1; : : : ; Hmg. Note here that in the de nition the program P is augmented with the atoms in A, which are then treated as additional facts. Example 3.3 Consider the program P = fa b; a c; b_ cg from Example 2.1. T c P (;) = f(b; fcg; ;); (c; fbg; ;); (b; ;; fbg); (c; ;; fcg); : : :g T c P (T c P (;)) = T c P (;)[ f(a; fcg; ;); (a; fbg; ;); (a; ;; fbg); (a; ;; fcg); : : :g In this example, dots are written to imply the inclusion of all triples which extend other triples in the set by adding b and/or c to the third component. For example, since the triple (b; fcg; ;) is in T c P (;), the triples (b; fcg; fbg), (b; fcg; fcg), and (b; fcg; fb;cg) will also be in T c P (;). Recall that the third component of a triple corresponds to the added facts in the case (active heads in the block). The presence of these extra triples re ects the fact 10 that given a derivation from some case, that derivation will succeed for all cases which are identical except for having additional facts. A variant of the case operator which minimizes the use of added facts is discussed at the end of this section. It is not di cult to see that 2TRIPP under is a complete lattice. It can be shown that T c P is continuous, and so has a least xpoint which is T c P " !. In Example 3.3 above, further iteration of the case operator produces the same set, and so the least xpoint T c P " ! = T c P (T c P (;)). The following theorem veri es that the case operator T c P produces precisely those triples corresponding to InH-Prolog blocks. Theorem 3.4 Given disjunctive logic program P , L 2 HBP , and nite D 2 2AuxP and A 2 2AuxP : (L;D;A) 2 T c P " ! i there exists an InH-Prolog block from P with initial goal L, nal deferred heads D, and active heads A. We are now ready to de ne the join operator which will build upon the information provided by the case operator. Recall that the splitting rule allows one to infer that a disjunction is a logical consequence of some program if it follows from a set of cases. This approach is apparent in InH-Prolog where a proof is a collection of blocks, each block being a derivation from one of the cases. Similarly, the join operator combines triples from the least xpoint of the case operator (which correspond to InH-Prolog blocks) in order to obtain the logical consequences of the original program. The join operator operates on sets of pairs of the form (~ L;A), taken from the space PAIRP = EHBP 2AuxP (where EHBP is the Extended Herbrand Base of P , consisting of all ground positive disjunctions). The pair (~ L;A) is intended to represent that positive disjunction ~ L follows from program P augmented with the facts in A. De nition 3.5 (Join Operator) Given disjunctive logic program P , ~ L 2 EHBP , nite A 2 2AuxP , and S 2 2PAIRP : (~ L;A) 2 T j P (S) i there exists nite D 2 2AuxP such that 1. (L0; D; A) 2 T c P " ! AND 2. 8di 2 D, there exists ( ~ Li; A[ fdig) 2 S, where ~ L is the smallest factor of L0 _ f_ ~ Lig. Example 3.6 Consider the program P = fa b; a c; b_ cg. >From Example 3.3, we have that T c P " ! = f(b; fcg; ;); (c; fbg; ;); (b; ;; fbg); (c; ;; fcg); f(a; fcg; ;); (a; fbg; ;); (a; ;; fbg); (a; ;; fcg); : : :g >From this and the de nition of T j P , we have that T j P (;) = f(b; fbg); (c; fcg); (a; fbg); (a; fcg); : : :g T j P (T j P (;)) = T j P (;)[ f(b _ c; ;); (a_ b; ;); (a_ c; ;); (a; ;); : : :g 11 T j P (T j P (T j P (;))) = T j P (T j P (;))[ f(a_ b _ c; ;); : : :g As in Example 3.3, the dots in the sets are written to imply the inclusion of pairs which extend other pairs in the set by adding b and/or c to the second component. Again, this re ects the fact that unnecessary added facts (active heads) are allowed. See the end of this section for a discussion of the variant of the join operator which minimizes the use of added facts. It is not di cult to see that 2PAIRP under is a complete lattice. It can be shown that T j P is continuous, and so has a least xpoint which is T j P " !. In Example 3.2, the least xpoint is achieved with T j P (T j P (T j P (;))). The following theorem veri es that the join operator T j P produces precisely those pairs corresponding to the InH-Prolog answer set. Theorem 3.7 Given disjunctive logic program P , ~ L 2 EHBP , and nite A 2 2AuxP : (~ L;A) 2 T j P " ! i there exists an InH-Prolog proof from P [A with computed answer clause ~ L. We may note that Theorem 3.7 takes on special interest when A is taken to be the empty set. The theorem then shows that pairs of the form (~ L; ;) in T j P " ! correspond to the computed answer clauses for InH-Prolog proofs from P . Thus, ground disjunction ~ L is in the InH-Prolog answer set if and only if (~ L; ;) 2 T j P " !. The fact that the join operator, building upon the case operator, characterizes the InHProlog answer set is signi cant. We mentioned earlier that InH-Prolog is complete in the sense that if 9~ L is a logical consequence of disjunctive logic program P , then there exists an InH-Prolog proof of 9~ L from P . In particular, there exists a proof of query 9~ L with computed answer clause ~ L0, where ~ L0 logically implies the query. The xpoint characterization (using the case and join operators) allows us to di erentiate between those consequences which are computed answer clauses (in a sense \minimal") and those which are simply provable. In particular, given a speci c program and query the xpoint characterization gives us a handle on the answer set for that query, i.e. the clauses which may be returned by InH-Prolog proofs of the query. One advantage of the xpoint characterization provided by the case operator and join operator is its close relationship to the standard characterization of Horn programs by van Emden and Kowalski [vEK76]. The following result shows that when applied to Horn programs, the case operator T c P \reduces" to the immediate consequence operator TP , i.e. produces the triple (L; ;; ;) precisely when TP produces the atom L. Theorem 3.8 Given Horn program P , L 2 HBP , and ordinal : L 2 TP " i (L; ;; ;) 2 T c P " . Likewise, when applied to Horn programs the join operator also reduces to the immediate consequence operator. (This is not surprising since the join operator is designed to combine the information obtainable via splitting rule cases, and so becomes transparent when applied to Horn programs.) 12 Theorem 3.9 Given Horn program P and L 2 HBP : L 2 TP " ! i (L; ;) 2 T j P " !. Thus, when the program is Horn our xpoint characterization reduces to the standard Horn characterization. We may note that Minker's monotone operator also reduces to the immediate consequence operator when applied to Horn programs. However, our xpoint characterization di ers from Minker's in that it maintains a close correlation to the Horn characterization even for non-Horn programs. The case operator may be viewed as retaining the behavior of the immediate consequence operator, only using Horn clauses \derived" from the disjunctive program. In particular, the case operator mimics the immediate consequence operator using a splitting rule case. Recall that the splitting rule reduces programs by either stripping heads o of a non-Horn clause or else by replacing a non-Horn clause with a subsuming fact. Thus, a particular splitting rule case can be described by the notation split(P,D,A), where P is the original program, D is the set of heads that are stripped o of non-Horn clauses, and A is the set of added facts. Using this notation, we can state the following result. (Note: the use of subset D0 in the second part of the following theorem is due to the fact that the case operator minimizes the set D. It is possible for a splitting rule case to contain stripped clauses which are not necessary for showing the logical consequence of the goal. In this case, the unnecessary stripped heads may not appear in a triple in the xpoint of the case operator.) Theorem 3.10 Given disjunctive program P , L 2 HBP , nite D 2 2AuxP and A 2 2AuxP , and ordinal : 1. if (L;D;A) 2 T c P " then L 2 Tsplit(P;D;A) " for some splitting rule case split(P,D,A). 2. if L 2 Tsplit(P;D;A) " then (L;D0; A) 2 T c P " for some D0 D. The close relationship to the standard Horn semantics leads to another advantage of this case-analysis based approach: the ability to neatly focus attention on the class of de nite (single atom) consequences of a program. In practice, one is often concerned only with single atom consequences. For example, given program P and non-ground query atom L one may want to show that 9L follows from P by producing a single instance of 9L which is a logical consequence of P . Example 3.11 Consider the following program, a variant of an example from [LR91], which encodes a simple planning problem: go(home,island,Time,via(X,Y)) go(home,shore,Time,via(X)) ^ go(shore,island,Time,via(Y)) go(home,shore,Time,via(hwy40)) go(shore,island,day,via(ferry)) _ go(shore,island,night,via(ferry)) go(shore,island,day,via(causeway)) 13 Here, the intended meaning of predicate go(Place1,Place2,Time,Route) is that it is possible to go from Place1 to Place2 at the given Time via the Route. For example, the second clause is a fact stating that it is possible to go from home to the shore at any time via highway 40. The reader should pay special attention to the third clause, whose intended meaning is that the ferry is known to travel from the shore to the island once a day, but that it is not known whether that trip is during the day or night. The disjunctive fact indicates that one of these alternatives must hold, but that it is not known which holds. Suppose one is interested in planning a route from home to the island, i.e. nding an instantiation of go(home,island,Time,Route) which is a logical consequence of the program. The disjunctive consequence go(home,island,day,via(hwy40,ferry)) _ go(home,island, night,via(hwy40,ferry)) shows that there is a solution, but it provides no de nite plan. If consequences are restricted to being de nite, this solution is rejected and a useful solution is found: go(home,island,day,via(hwy40,causeway)). >From the description of an InH-Prolog proof, we can see that a proof of de nite consequence L will consist of blocks, all of which will start with goal L. Recall that Theorem 3.4 and Theorem 3.7 tell us that triples in the xpoint of the case operator correspond to InH-Prolog blocks and pairs in the xpoint of the join operator correspond to InH-Prolog proofs. Thus, when restricting attention to de nite consequences only, we may note that the join operator need only combine triples with the same rst component. This allows us to simplify the description of the join operator to the following: De nition 3.12 (De nite Join Operator) Given disjunctive program P , L 2 HBP , nite A 2 2AuxP , and S 2 2PAIRP : (L;A) 2 T j P (S) i there exists nite D 2 2AuxP such that 1. (L;D;A) 2 T c P " ! AND 2. 8di 2 D, (L;A[ fdig) 2 S. Since the join operator now utilizes only single atom consequences, as does the case operator, all de nite consequences of the program are obtained without any reference to disjunctive consequences. Thus, for this interesting class of consequences our xpoint characterization reduces to be even nearer to the Horn characterization using the immediate consequence operator. Minker's characterization does not provide for such a simpli cation since disjunctions are the basic units for his monotone operator. The following example demonstrates how the join operator is simpli ed when restricted to de nite consequences. Example 3.13 Consider again the program P = fa b, a c, b _ cg from Example 3.3. As before, we have that 14 T c P " ! = f(b,fcg,;), (c,fbg,;), (b,;,fbg), (c,;,fcg), (a,fcg,;), (a,fbg,;), (a,;,fbg), (a,;,fcg), : : : g When restricted to de nite consequences, the simpli ed join operator produces the following T j P (;) = f(b,fbg), (c,fcg), (a,fbg), (a,fcg), : : : g T j P (T j P (;)) = T j P (;) [ f(a,;), : : : g Further iteration shows that the least xpoint is achieved with T j P (T j P (;)). Before concluding this section, we should re-emphasize the point that the case and join operators described here correspond to InH-Prolog blocks and proofs in which the cancellation pruning rule is ignored. This is due to the fact that added facts (the \A" term in pairs and triples) are not minimized. There do exist, however, variants of the case operator and join operator which do minimize the use of added facts. These variants, call them T c P and T j P , are conceptually very close to the operators presented in this paper, though space considerations preclude their full description. The basic idea behind these variants is to rst ensure that the case operator T c P produces the triple (L;D;A) only if there is a corresponding InH-Prolog block in which all active heads in A are used in a cancellation. Then, the join operator T j P joins these minimal blocks, again forcing the necessity of all active heads. Results similar to those presented for T c P and T j P have been proven using the variants T j P and T c P . In particular, it can be shown that these variants match the InH-Prolog procedure including the cancellation pruning rule. 3.2 Negation Within the logic programming community, declarative semantics are generally motivated by the need to incorporate and understand negation. For reasons of e ciency, some form of default negation is usually selected. This is especially true in application areas such as arti cial intelligence and databases, where large amounts of negative information must be handled. A standard example is the following rule from a database on animals can fly(X) is bird(X)^ :injured(X) which states that non-injured birds can y. It would be tedious and possibly overwhelming to have to include a negative fact for every bird in the database that is not injured. Since being injured is a rare occurrence, it is preferable to assume that a bird is not injured unless it is speci cally stated otherwise. Thus, default negation is desirable. Within Horn clause logic a good case can be made that default negation based on the Closed World Assumption (CWA) is su cient. It is well-known that a minimal model exists for every positive Horn program, and any atom not in that model can reasonably be regarded as false (i.e. its negation may be assumed true). However, there is reason to question wholesale adoption of default negation even here, as illustrated by McCarthy's example given in Gelfond and Lifschitz [GL90]. They mention a knowledge base for driving a school bus that contains the rule cross tracks :train coming 15 which states that if there is not a train coming, the bus can cross the railroad tracks. In such an application, default reasoning is not su cient since the absence of evidence about a train should not justify crossing the tracks. Instead, the tracks should be crossed only after explicit information has been obtained which shows that a train is not approaching (e.g. the driver looks both ways). A natural way to require that a negated statement is a consequence of the database before the statement is considered true is to utilize classical negation. By this we mean the use of some variant of classical logic where a negative assertion must have a formal proof just as for a positive statement. There is even more reason to consider classical negation when working with disjunctive logic. Classical negation is closely linked to the natural case-analysis approach to reasoning with disjunctive information. Negative information is useful in re ning the consequences of a disjunctive program by essentially eliminating cases in the case analysis. The following example illustrates this property. Example 3.14 Consider a database containing information about a murder investigation. It is known that either John or Frank is the killer, and that in general a killer must have both a motive and opportunity. killer(john) _ killer(frank) motive(Suspect) killer(Suspect) opportunity(Suspect) killer(Suspect) Since no information is known regarding motive or opportunity for either suspect, nothing beyond the inde nite fact that either John or Frank is the killer can be inferred. However, if it is determined that Frank has an alibi, the negative fact :opportunity(frank) could be added to the program, constraining the inde nite consequence and forcing the de nite consequence killer(john). The case-analysis nature of InH-Prolog makes it an ideal deduction mechanism for reasoning with classical negation. However, the InH-Prolog procedure was originally de ned to infer positive information from positive disjunctive logic programs. Handling classical negation within disjunctive program clauses is a simple task since negative goals in a clause can be moved to the head of the clause and made positive. For example, the clause concerning the school bus can be rewritten (using the classical interpretation of negation) as cross tracks_ train coming: In order to make use of InH-Prolog in the presence of negative facts (either negative literals or disjunctions of negative literals), we use a slight encoding trick. We represent negative facts as positive clauses which have a new, reserved atom FALSE as head. For example, negative facts :a and :b _ :c are represented as positive clauses FALSE a and FALSE b ^ c, respectively. We say that these positive clauses using FALSE are the positive encodings of the negative facts. The intended meaning of these negative facts is then obtained by using their positive encodings and assuming that the new atom FALSE has a priori value false. The advantage in representing negative facts in this manner is the 16 uniformity obtained among the clauses. Ignoring the fact that FALSE is intended to have value false, a disjunctive logic program with encoded negative facts still has the form of a positive program. The following result shows that disjunction of atoms ~ K follows from a program containing negative facts if and only if FALSE_ ~ K follows from the positive encoding of that program. De nition 3.15 Let N be a set of negative facts. By pos(N) we denote the set of positive encodings of facts in N , i.e. pos(N) = f FALSE L1 ^ ^ Ln j :L1 _ _ :Ln 2 N g. Theorem 3.16 Let P be a positive disjunctive logic program, N be a set of negative facts, and ~ K be a positive disjunction. P [N j= ~ K i P [ pos(N)[ f:FALSEg j= ~ K i P [ pos(N) j= FALSE _ ~ K. Since InH-Prolog is a sound and complete procedure for inferring positive information from positive disjunctive logic programs, this result implies that it can be extended to make use of negative facts by positively encoding the facts and allowing FALSE as start goal in blocks. (The disjunct FALSE is ignored in any returned answer.) Example 3.17 Consider the program from Example 3.14, augmented with the new clause FALSE opportunity(frank) (the positive encoding of :opportunity(frank)). killer(john) _ killer(frank) motive(Suspect) killer(Suspect) opportunity(Suspect) killer(Suspect) FALSE opportunity(frank) >From this augmented program, the following InH-Prolog proof of killer(john) is obtained. ?killer(john) :# f killer(frank)g restart: ?FALSE # killer(frank) :opportunity(frank) # killer(frank) :killer(frank) # killer(frank) :# killer(frank) Here, the restart block has initial goal FALSE, calling the positive encoding of the negative fact. Since FALSE does not contribute to the returned answer, the negative fact is essentially used to eliminate the case where the conditional fact killer(frank) holds. 17 In addition to positive consequences, it is also possible to handle negative goals to a disjunctive logic program. Using a refutation strategy, :A can be proven to be a consequence of a program P if the addition of fact A to P produces a contradiction. In terms of the InH-Prolog procedure above, a contradiction is proven by constructing an InH-Prolog proof of FALSE. Thus, a negative fact :A can be proven by adding fact A to the program and then constructing an InH-Prolog proof with FALSE as start goal of each block. Example 3.18 Consider the program from Example 3.17. In order to prove that Frank is not the killer, we add killer(frank) to the program and obtain a refutation by deriving FALSE. ?FALSE :opportunity(Frank) :killer(Frank) :While classical negation appears naturally and can easily be added to disjunctive logic programs, we have seen that it is not always the desirable approach. The near-Horn Prologs are amenable to the addition of default negation as well as classical negation. In particular, the Generalized Closed World Assumption (GCWA) [Min82] and the Weak Generalized Closed World (WGCWA) [RLM89, RT88] have been investigated. The GCWA generalizes the Closed World Assumption by considering all minimal models of a disjunctive program. The following de nition presents equivalent formulations of the GCWA: De nition 3.19 (GCWA) Let P be a disjunctive logic program and A 2 HBP . Formulation 1: :A may be assumed i A is false in all minimal models of P . Formulation 2: :A may be assumed i A does not appear in any minimal consequence of P . Formulation 3: :A may be assumed i A 62 atoms(min(T j P " !)). Here, the notation min(T j P " !) represents those minimal logical consequences captured by the xpoint of T j P , i.e. those disjunctions of atoms ~ L for which (~ L; ;) 2 T j P " ! and for which no subclause ~ L0 is (~ L0; ;) 2 T j P " !. Both the second and third formulations of the GCWA focus on minimal consequences of a program, suggesting computational complexity since they imply that a default mechanism is forced to test for the minimality of consequences. While the GCWA can be incorporated into nH-Prolog, we instead focus on the theoretically weaker but computationally simpler WGCWA. The WGCWA is de ned as follows: De nition 3.20 (WGCWA) Let P be a disjunctive logic program and A 2 HBP . Formulation 1: :A may be assumed i A _ ~ K is not \derivable" (for any ~ K). Formulation 2: :A may be assumed i A 62 atoms(T j P " !). 18 Here, the notion of \derivable" originally referred to derivability using resolution (i.e. a disjunction of atoms is "derivable" if there exists a resolution derivation of it). However, derivability can refer to other sound and complete proof systems, such as InH-Prolog. In fact, the case-analysis nature of InH-Prolog makes it ideal for implementing the WGCWA since attention need not be focused on entire derivations, but instead can focus on individual blocks. It can be shown that negative goal :A is assumed by the WGCWA if and only if there is no complete InH-Prolog start block with initial goal A. Making use of nite failure, the WGCWA has been incorporated into InH-Prolog via the Negation as Finite Block Failure (NAFBF) rule [Ree91]. De nition 3.21 (NAFBF Rule) Let P be a disjunctive logic program and A 2 HBP . :A may be assumed i all InH-Prolog start blocks from P with initial goal A nitely fail. Recall that an InH-Prolog block is basically a Prolog derivation of the initial goal, and so this rule is very similar to the standard Negation as Failure (NAF) rule for Horn programs. In fact, the following result shows that the negative literals assumed from P by the NAFBF rule are identical to those assumed from Horn(P ) by the NAF rule. Theorem 3.22 Let P be a positive disjunctive logic program. NAFBF(P ) = NAF(Horn(P)). It should also be noted that the NAFBF rule coincides with the NAFFD rule of [RLM89]. This is due to the fact that InH-Prolog blocks map directly to SLINF-trees, which are the basis of the NAFFD rule. With the addition of default negation through a rule such as NAFBF, InH-Prolog then becomes an excellent vehicle for researching the combination of both classical and default negation. Earlier examples in this paper argue for the usefulness of each type of negation in certain applications. In addition, it is interesting to envision applications in which both types of negation would be useful and must interact. Consider a database for hospital management. Default negation would likely su ce for most rules. For example, there might be a rule of the form feed(Patient; hash) :requested(Patient; vegetarian) which states that a patient is to be fed hash as long as that patient did not request a vegetarian meal. Default negation is preferable here since only a small percentage of patients are likely to be vegetarians and a possible mistake is not too serious. However, there might also be rules for which explicit classical negation is required. For example, there might be a rule administer(Patient,Drug) prescribed(Patient,Drug) ^ :allergic to(Patient,Drug) 19 which instructs a nurse to administer the prescribed drug as long as the patient is not allergic to the drug. In such a case of life and death, the mere fact that the nurse has no evidence to the fact that the patient is allergic is not su cient. Instead, explicit information to that e ect must be found. It is important to note that if classical and default negation are both to be used in a program, then special care must be taken to ensure the reliability of classical negation. For example, consider the hospital example above, where classical negation forces a search to prove that the patient is not allergic to the drug. If that search at some point utilizes default negation, then the reliability of the proof is compromised (or at least made dependent on the default mechanism). Thus, the programmer must ensure that the proof of a classically negated goal cannot involve default negation. Assuming only positive queries to a program, this can safely be accomplished by a preprocessor which inspects a program and determines whether any negative goals (using default negation) are reachable from classically negated goals. It is also important to understand the relationship between the two types of negation if they are to interact. For example, it would be desirable to have the default negation be complete with respect to classical negation. That is, if :A follows classically from a program, then it should also follow by the default rule. This is a natural property to expect since a default rule is intended to capture those negative facts which are \safe" to assume, and it certainly is safe to assume logical consequences. The GCWA is complete with respect to classical negation since if :A is a logical consequence of some program P , any positive consequence containing A cannot be minimal (since P j= :A and P j= A _ ~ K implies that P j= ~ K). In contrast, the WGCWA does not have this property. Consider the program P = f:a, a b, b _ cg. The disjunction a _ c is derivable from P , and so :a cannot be assumed by the WGCWA. The WGCWA can easily be extended to include the classical consequences of the program. For example, we could de ne aWGCWA+ rule which assumed negative literal :A if and only if either :A is a logical consequence of the program or :A follows by the WGCWA. However, while it is desirable in theory to have a default negation which is complete with respect to classical negation, it is not necessarily important in a practical sense. Even though the GCWA is complete with respect to classical negation, any procedural de nition of the GCWA which takes nite failure into account will fail to have this property. For example, given the program P = f:a, a b, b ag, :a follows both classically and from the GCWA. However, an implementation of the GCWA using nite failure will not be able to assume :a since the attempted derivation of a loops. Likewise, the WGCWA+ could be implemented by combining the NAFBF procedure and the InH-Prolog refutation mechanism for handling classically negated goals. Still, loops might occur which would preclude assuming a negative literal even though that literal follows classically. 4 Implementation The near-Horn Prologs were designed to be simple and e cient extensions to Prolog. Since the practicality of these (and any) procedures depends upon the e ciency and ease of use of their implementations, an important focus of the near-Horn Prolog project has been to 20 produce e cient implementations which retain the Prolog style. An interpreter for the UnHProlog variant has been implemented [SL88], and a prototype compiler for the InH-Prolog variant is currently nearing completion. Just as the procedural variants of nH-Prolog display many similarities, the implementations of the variants look much the same to their users. Before describing the techniques used to implement the nH-Prologs, we brie y describe this common \look and feel". All implementations of nH-Prolog use the standard Prolog in x operators `,', `;' and `:-' to represent the logical operators ^, _ and . As in Prolog, the implementations do not (by default) display proofs but instead return the computed answers which are instantiations of the given query. When the user's query contains a variable, the response returned may be a disjunctive instance of the query. Example 4.1 Consider the following non-ground program P . p(X) :q(X). % p(X) q(X) p(X) :r(X). % p(X) r(X) q(a) ; r(b). % q(a) _ r(b) Given the query ?p(X), the response will be p(a) -OR -p(b), a disjunctive instance of the query that is a consequence of the program. The -OR -in a displayed answer alerts the user to a (perhaps unexpected) disjunctive answer. As in Prolog, when an answer is reported the user has an option of searching for alternative answers by entering a semi-colon. Since all nH-Prolog implementations report an answer for each proof (as Prolog does), this means an answer substitution will be repeated if it is computed by more than one proof. In nH-Prolog, not only may an answer be repeated, but one answer may be a generalization of another. Example 4.2 Consider the following program P . p(a). p(a) ; p(b). q(c). Given the query ?p(X), the answer p(a) will be reported, followed by the alternative answer p(a) -OR -p(b) (assuming the user enters a semi-colon). These two are the only answers that will be reported, that is, the entry of another semi-colon will result in a failed proof attempt. In particular, it should be noted that the disjunction p(a) -OR -p(b) -OR -p(c) is not reported, even though it is both a disjunctive instance of the query and a logical consequence of the program. For details of which logical consequences of a program are computed answers, the reader is referred to section 3. 21 4.1 UnH-Prolog meta-interpreter The rst implementation of nH-Prolog was a meta-interpreter for the UnH-Prolog variant. It represents the clauses of an nH-Prolog program as a set of facts in the Prolog database. A Horn clause head :body is represented as a fact nH(head, body). A non-Horn clause head1 ; : : : ; headn :body is represented as a set of facts nH(headi, DHListi, body, AList), for i = 1; : : :n. Each DHListi is the list of all elements of the form dh(headj, AList), for j 6= i. AList is the list of ancestor goals, to be used in the case of a restart. At runtime, AList becomes bound to the goal's ancestor list. The atoms of an ancestor list share variables, and hence have bindings determined by subsequent instantiation of calling goals. When ancestor list atoms are used as restart goals, these bindings are used rather than using new variables. A top-level procedure reads the user's query and makes it the goal of the initial block. (This initial implementation does not handle disjunctive queries, although extending it to do so is a straightforward task.) When any block successfully completes with no remaining deferred heads, the top-level reports an answer instance of the query. When a block successfully completes with remaining deferred heads, an active head and an appropriate restart goal are chosen to begin a new block. The restart goal can be chosen from the active head's ancestor list, or it can be the special goal FALSE for handling negations, or it can be a \new" copy of the user's query. The last case introduces disjunctions into answer instances. Within a block, the inner loop of the meta-interpreter is a predicate nH solve, which looks much like a standard Prolog meta-interpreter, except for two clauses special to nHProlog. One handles the calling of nH-Prolog clauses and the other cancellation with an active head. A simpli ed version of the former is nH_solve(Goal, AH, Anc, DH0, DH, Cancel) :nH_index(Goal, RefList), append(_, [ChosenRef|Refs], RefList), clause(ChosenClause, _, ChosenRef), NewAnc = [anc(Goal, RestRef)|Anc], ( ChosenClause = nH(Goal, Body) -> nH_solve(Body, AH, NewAnc, DH0, DH, Cancel) ; ChosenClause = nH(Goal, AuxHeads, Body, NewAnc) -> append(AuxHeads, DH0, DH1), nH_solve(Body, AH, NewAnc, DH1, DH, Cancel) ). The predicate nH index returns a list of database references of candidate nH-Prolog clauses. Those candidate clauses which are untried become the second argument to an anc-structure at the head of the new ancestor list NewAnc. (The remaining clauses are used in the restart blocks created for the deferred heads. The case shown here is referred to as \no wrap".) The variables DH0, DH1, and DH are a list accumulator for deferred heads created within the block. Cancellation is handled by the clause 22 nH_solve(Goal, Goal, _, _, DH, DH, yes). The second argument, called AH above, is the active head which, in this case, uni es with the goal. The cancellation pruning rule is enforced by requiring Cancel to have the value yes at the end of any restart block. Note that active heads, ancestor goals and deferred heads cannot simply be stored in the Prolog database by asserting. This is because of shared variables. For example, suppose that p(X) and q(X) are deferred heads, and that when p(X) is active it is used to cancel a goal p(a). The other head, then, can only be used to cancel a goal q(a). Otherwise, the system is unsound. This comment applies equally to the active and deferred heads in InH-Prolog. The meta-interpreter was implemented in version 2.4 of Quintus Prolog. It executes Horn clause programs, such as naive reverse, at about 1/4 the speed of the Quintus interpreter. Since the run-time treatment of Horn and non-Horn clauses di ers only in one clause of nH solve, it is reasonable to compare its performance with Prolog's by a simple lips rate. 4.2 InH-Prolog prototype compiler When moving from an interpreter to a compiler to realize increased performance, we shift nH-Prolog variants. As previously remarked, with a compiler we can take advantage of the more powerful cancellation rule of InH-Prolog while minimizing the cost of multiple active heads by preconditioning our input clauses. The prototype compiler for InH-Prolog translates nH-Prolog programs into Prolog programs, which are then compiled and executed. The top-level procedure is similar to that of the UnH-Prolog meta-interpreter, as is the procedure that manages blocks. However, rather than having the nH solve predicate of the meta-interpreter's inner loop, this is built into the the nH-Prolog clauses by the translation process. To simplify the translation task, the whole nH-Prolog program is contained in one le. Before translation, predicates are divided into three categories: non-Horn predicates that have at least one non-Horn clause, Horn predicates that have only Horn clauses and that call only Horn predicates, and mixed predicates that have only Horn clauses but that may call any predicates. After the classi cation of predicates, the program is translated clause by clause. Horn predicate clauses are left unchanged by translation. Non-Horn and mixed predicate clauses are given extra arguments. Each non-Horn predicate is given a new rst clause, and a new predicate is created to record whether the predicate occurs as an active head. Since non-Horn and mixed predicates have added arguments, calls to them within clause bodies must also be modi ed. The translation is best explained by a (simpli ed) example. Example 4.3 Consider the following non-Horn clause in a disjunctive program P . p(X, Y) ; q(Y, X) :r(X, Y), % r is non-Horn or mixed 23 s(X, Y).% s is HornThe added arguments will be V, used for the bindings of active heads, and a pair D0 andD used as a list accumulator for deferred heads. To simplify this example, we ignore thecancellation pruning rule. This clause belongs to both procedures p and q, since it containsboth as head literals, but we only consider its contribution to p.Since p may be deferred by this clause (when used as part of the q procedure), the pprocedure gets a new rst clause, to perform cancellations:p(X, Y, V, D, D) :-p active(I),check bindings(V, I, [X, Y]).The predicate p active fails if there is no active head with predicate p. Otherwise, it returnsthe index of that head's arguments in V. The predicate check bindings tests whether thearguments of the goal and active head unify.The translation of the clause itself looks like this:p(X, Y, V, D0, D1) :-D1 = [ q(Y, X) | D0],r(X, Y, D1, D),s(X, Y).Calling this clause defers a head q(Y, X). The new list if deferred heads and the bindings inV are passed as arguments in the call to r, but the Horn predicate s needs only the originalarguments X and Y.Since Horn predicates are unchanged by the translation, the performance of programs(or sub-programs) consisting entirely of Horn predicates is identical to that of Prolog. Thissupports our conviction that the cost of nH-Prolog should depend on the number of non-Horn clauses. In addition, this compiler implementation is able to almost alleviate theinner-loop speed disadvantage of InH-Prolog. Recall that multiple active heads in InH-Prolog can lead to shorter and more direct proofs, but also cause the inner-loop speed to beproportional to the block depth. As described above, the compiler handles the cancellationof active heads by adding a special clause at the beginning of the procedures for potentialactive heads. This new clause is accessed with the same e ciency that is provided for regulardeduction, so it amounts to a program lengthened by another clause or so. If all active headsin a program are distinct, this mechanism duplicates the e ciency of UnH-Prolog since acalling goal calls the appropriate procedure, rst encountering the new cancellation clause,and then moving to the regular procedure clauses. If, however, di erent active heads aremembers of the same procedure, the mechanism will not provide for constant-time treatmentof active heads since the check bindings goal may backtrack through multiple bindings.Still, the inner-loop speed is proportional to the number of active heads which are instancesof the given procedure, which is likely to be an improvement.24 AcknowledgementsThe research was partially supported by ARO Grant DAAL03-88-K-0082 and NSF GrantsIRI-8805696 and CCR-8900383.References[Gen69] G. Gentzen. Investigations into logical deductions. In M.E. Szabo, editor, Thecollected papers of Gerhard Gentzen, pages 68{131. North-Holland PublishingCompany, Amsterdam, 1969.[GL90] M. Gelfond and V. Lifschitz. Logic programs with classical negation. In D.H.D.Warren and P. Szeredi, editors, Logic Programming: Proc. of the Seventh Int'lConf., Jerusalem, Israel, 1990. MIT Press.[KK71] R. Kowalski and D. Kuehner. Linear resolution with selection function. Arti cialIntelligence, 2:227{260, 1971.[LMR89] J. Lobo, J. Minker, and A. Rajasekar. Extending the semantics of logic pro-grams to disjunctive logic programs. In G. Levi and M. Martelli, editors, LogicProgramming: Proc. of the Sixth Int'l Conf., Lisbon, Portugal, 1989.[LN]D.W. Loveland and G. Nadathur. Handbook for Logic in AI and Logic Pro-gramming, volume 4, chapter Proof Procedures for Logic Programming. OxfordUniversity Press. (to appear).[Lov68] D.W. Loveland. Mechanical theorem proving by model elimination. J. ACM,15:236{251, 1968.[Lov69] D.W. Loveland. A simpli ed format for the model elimination procedure. J.ACM, 16:349{363, 1969.[Lov78] D.W. Loveland. Automated Theorem Proving: A Logical Basis. North-Holland,Amsterdam, 1978.[Lov87] D.W. Loveland. Near-Horn Prolog. In J. Lassez, editor, Logic Programming:Proc. of the Fourth Int'l Conf., pages 456{469. MIT Press, 1987.[Lov91] D.W. Loveland. Near-Horn Prolog and beyond. J. Automated Reasoning, 7:1{26,1991.[LR91] D.W. Loveland and D.W. Reed. A near-Horn Prolog for compilation. In J. Lassezand G. Plotkin, editors, Computational Logic: Essays in Honor of Alan Robinson.MIT Press, 1991.[Min82] J. Minker. On inde nite databases and the closed world assumption. In LectureNotes in Computer Science 138, pages 292{308. Springer-Verlag, Berlin, 1982.25 [MR90] J. Minker and A. Rajasekar. A xpoint semantics for disjunctive logic programs.J. Logic Programming, 9(1):45{74, 1990.[MZ82] J. Minker and G. Zanon. An extension to linear resolution with selection function.Information Processing Letters, 14(3):191{194, 1982.[Ree91] D.W. Reed. A Case-analysis Approach to Disjunctive Logic Programming. PhDthesis, Duke University, December 1991.[RL89] D.W. Reed and D.W. Loveland. A comparison of three Prolog extensions. Techni-cal Report CS-1989-8, Duke University, 1989. To appear in J. Logic Programming.[RLM89] A. Rajasekar, J. Lobo, and J. Minker. Weak generalized closed world assumption.J. Automated Reasoning, 5:293{307, 1989.[RLS91] D.W. Reed, D.W. Loveland, and B.T. Smith. An alternative characterization ofdisjunctive logic programs. In V. Saraswat and K. Ueda, editors, Logic Program-ming: Proc. of the 1991 Int'l Symp. MIT Press, 1991.[RT88] K.A. Ross and R.W. Topor. Inferring negative information from disjunctivedatabases. J. Automated Reasoning, 4(2):397{424, 1988.[SL88] B.T. Smith and D.W. Loveland. A simple near-Horn Prolog interpreter. InKowalski and Bowen, editors, Logic Programming: Proc. of the Fifth Int'l Conf.and Symp., pages 794{809. MIT Press, 1988.[vEK76] M.H. van Emden and R.A. Kowalski. The semantics of predicate logic as a pro-gramming language. J. ACM, 23(4):733{742, 1976.26